Electronic document content, including textual, graphic and/or interactive elements, generally does not by itself provide information related to how it should be presented for viewing. Several “markup languages” have been developed to provide such presentation information, and can direct a content-rendering application to present the content in a specified manner. In many cases the markup language includes “tags” that serve to mark a portion of content. The tags may directly provide information for formatting or may serve simply as a marker. In the latter case, a style sheet can be implemented to instruct a content-rendering application how to display the document based on the tags. The markup language is generally not displayed to an end-user viewer.
When developing or testing content for Internet or intranet consumption, a careful developer or tester typically should consider how different content-rendering applications may render the content. Even if particular care is employed to address known rendering differences, one or more elements of the content may be rendered with certain properties and dimensions in one web-browser, for example, while appearing to have different properties or dimensions in another web-browser. When a tester uses automatic testing software to test a web-page in different browsers, various elements of the displayed content may be tested for functionality. For example, a clickable button or a hyperlink may be clicked to ensure accuracy of functionality, or that the target of the hyperlink is valid. The test may fail, however, if the clickable button or hyperlink is displayed with one size and location in one web-browser while another web browser may display the button or hyperlink having a different size and/or location.
In just one example, for many years Microsoft Corporation's well-known Internet Explorer™ web browser has through several versions provided varying levels of support for common markup standards. Due to the historical ubiquity of the browser, and the variety in software versions still in use, prudent developers of web content and/or web applications must consider how such web content will appear when rendered by at least the most common browser versions. Add to this the different versions of several popular competing web-browser applications, each having its own variations in interpretation and compliance with support for markup standards, and it is easy to see how a conventional content testing environment could be complicated by the variations in content-rendering applications.
In conventional test environment using automated testing means (such as testing software), rendered content may be satisfactorily tested for functionality, appearance, and/or other characteristics—so long as the size and location of content elements are as the automated means expects. In situations where the display of one or more elements varies in size or location, the automation may fail or otherwise provide an undesirable test result. When automated testing fails, a user may be required to manually compare size/location of the content rendered in each content-rendering application or make time-consuming manual adjustments to the test configuration only for a particular instantiation. The user may employ various means for such comparison, including programmatic comparison of screen captures. In this case, however, a single pixel difference, or a slight variation in color/font/size of the content can be reported as a difference requiring further, time-consuming, and ultimately unwarranted manual scrutiny.
Although generally reliable, manual testing and/or comparison is slow and costly in comparison with automated testing/comparison. For at least this reason, reliable full automation would benefit any content testing process, and may be particularly helpful in environments where a large volume of content is reviewed or tested. Minimizing manual (human-performed) comparison or testing of rendered content would thus save at least time and money.